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TSG-SA Working Group 1 (Services) meeting #8 TSG S1 (00) 370 
Beijing, China: 10-14th April 2000 Agenda Item: 6.12 

Source: TSG SA WG1 
Title: Liaison statement on hexadecimal IMEI format 

To: SA WG5, CN WG1, CN WG4, RAN WG2, RAN WG3, GSM Association 
CC: SA WG2, 

Contact: tommi.kokkola@nokia.com 

81 received the attached contribution to change IMEI format. 81 would like other WGs and 
GSM assiciation to study the proposal and comment. 

Change of the coding is proposed for release 2000. 81 asks the WGs to consider if this late 
proposal for R99 would be possible so that all the UMTS terminals could use this coding from 
the beginning. 

3GPP TSG-SA, WG1 meeting #8 TDoc S1#8 (00)0275 
Peking, China, April 10-15, 2000 

Source: Nokia 

Title: Proposal to modify IMEI format 

Background 
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The current IMEI format is structured in the following way: 

o Type Approval Code (TAG): 6 digits. The first 2 digits constitute the code allocated 
to Notified Body = Reporting Body ldentifier( 1900 MHz phones in USA and test 
terminals have different coding) 

o Final Assembly Code (FAC): 2 digits 

o Serial Number: 6 digits 

o Check digit 

These digits have been presented in BCD format. New Type Approval Codes have been 
issued with a 6 BCD digits Serial Number set (1 Million units) is not sufficient any more. This 
format has served well and no problems have been envisaged as far as an unambiguous 
terminal coding for GSM is concerned. However, the introduction of the IMEI into 3G mobile 
terminal identification changes the situation as soon as a great variety of products 
manufactured in larger volumes will flow to market place. Nevertheless, any modification in the 
IMEI coding must not jeopardize smooth migration from one mobile generation to the next one. 



Given the strong reliance on the interoperability with legacy products no change to IMEI length 
or structure is considered feasible. In contrast, the coding format of the Serial Number is 
proposed to be modified. 

• Instead using BCD, a hexadecimal code format is proposed. It would offer a capacity of 
16.7 Million units manufactured with one Type Approval Code. 

• TAC would set a trigger for interpretation ( Network would identify from which TAC 
number onwards a serial number would be interpreted as binary presentation) 



This proposal will require modifications to network management system for both installed and 
new (GSM and 3G). But no modifications to existing Rel *99 signalling is foreseen. 

Change of coding is proposed for release 2000. However, change should be considered 
already for release 1 999 in order to allow new IME coding in all 3G terminals. 

Attached CR to 22.016 for Release 2000. 



Proposal 



3GPP SA 



CHANGE REQUEST 
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A.1 Representation of IMEI 



The International Mobile station Equipment Identity and Software Version Number (IMEISV), as defined in TS 23.003, is a 
16 digit hexadecimal number composed of four distinct elements! 

- a 6 digit Type Approval Code (TAC); 

- a 2 digit Final Assembly Code (FAC); 

- a 6 digit Serial Number (SNR); and 

- a 2 digit Software Version Number (SVN). 

The IMEISV is formed by concatenating these four elements as illustrated below: 

I TAC \ FAC I SNR | SVN | 



Figure A.1: Composition of the IMEISV 

The IMEI is complemented by a check digit as defined in section 3. The modulus 16 Luhn Check Digit (CD) is computed 
on the 14 most significant hexadecimal digits of the IMEISV, that is on the value obtained by ignoring the SVN digits. 

The method for computing the Luhn check is defined in Annex B of the International Standard "Identification cards - 
Numbering system and registration procedure for issuer identifiers" (ISO/IEC 7812) [3]. The modulus 16 Luhn Check Digit 
is identical, but number base has been transformed fi'om 10 to 16. 

In order to specify precisely how the CD is computed for the IMEI, it is necessary to label the individual digits of the 
IMEISV, excluding the SVN. This is done as follows: 

The (14 most significant) digits of the IMEISV are labelled DI4 D13 ... Dl, where: 

- TAC = DI4 D13 ... D9 (with D9 the least significant digit of TAC); 

- FAC = D8 D7 (with D7 the least significant digit of FAC); and 

- SNR = D6 D5 ... Dl (with Dl the least significant digit of SNR). 

Note: Even though all digits Dl □ D14 are changed to use hexadecimal coding, this has no effect to the previously assigned 
values of all fields when the fields were using BCD coding. The same code values can still be used for the previously 
assigned codes. The hexadecimal coding allows more codes to be used for all fields. Especially this applies to the SNR field, 
which has number space of 2^24 = 16,777,216 units □ with BCD coding the number space is 1,000,000 units. 

A.2 Computation of CD for an IMEI 

Computation of CD fi'om the IMEI proceeds as follows: 

Step 1: Double the values of the odd labelled digits HI, H3, H5, ... H13 of the IMEI using hexadecimal 
number base. 

Step 2: Add together the individual digits of all the seven numbers obtained in Step 1, and then add this sum to 
the sum of all the even labelled digits H2, H4, H6, ... HI4 of the IMEI using hexadecimal number base. 
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Step 3: If the number obtained in Step 2 ends in 0, then set CD to be 0. If the number obtained in Step 2 does 
not end in 0, then set CD to be that number subtracted from the next higher hexadecimal number which does 
end in 0. 



A.3 Example of computation 

IMEI (14 most significant digits): 



TAG 


FAG 


SNR 


H14H13H12H11 H10 H9 


H8 H7 


H6 H5 H4 H3 H2 H1 


26053 1 


79 


38D3E3 



Step 1: 

260531 79 38D3E3 

x2 x2 x2 x2 x2 x2 x2 

G A 2 12 10 6 6 

Step 2: 

2+C+0+A+3+2+7+l+2+3+l+0+D+6+E+6=52 

Step 3: 

CD = 60 - 52 = E 
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Background 



The current IMEI format is structured in the following way: 



■ Type Approval Code (TAC): 6 digits. The first 2 digits constitute the code allocated to 
Notified Body = Reporting Body ldentifier( 1900 MHz phones in USA and test temiinals 
have different coding) 

■ Final Assembly Code (FAC): 2 digits 

■ Serial Number: 6 digits 

■ Check digit 



These digits have been presented in BCD format. New Type Approval Codes have been issued with a 6 
BCD digits Serial Number set (1 Million units) is not sufficient any more. This format has served well and 
no problems have been envisaged as far as an unambiguous terminal coding for GSM is concerned. 
However, the introduction of the IMEI into 3G mobile terminal identification changes the situation as soon 
as a great variety of products manufactured in larger volumes will flow to market place. Nevertheless, 
any modification in the IMEI coding must not jeopardize smooth migration from one mobile generation to 
the next one. 



Given the strong reliance on the interoperability with legacy products no change to IMEI length or 
structure is considered feasible. In contrast, the coding fomiat of the Serial Number is proposed to be 
modified. 

■ Instead using BCD, a hexadecimal code format is proposed. It would offer a capacity of 16.7 Million 
units manufactured with one Type Approval Code. 

■ TAC would set a trigger for interpretation ( Network would identify from which TAC number onwards 
a serial number would be interpreted as binary presentation) 

This proposal will require modifications to network management system for both installed and new (GSM 
and 3G). But no modifications to existing Rel '99 signalling is foreseen. 

Change of coding is proposed for release 2000. However, change should be considered already for 
release 1999 in order to allow new IME coding in all 30 tenminals. 

Attached CR to 22.016 for Release 2000. 
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Annex A (normative): 

IMEI Check Digit computation 



A.1 Representation of IMEI 



The International Mobile station Equipment Identity and Software Version Number (IMEISV), as defined in TS 23.003, is a 16 
digit hexa decimal number composed of four distinct elements: 

- a 6 digit Type Approval Code (TAC); 

- a 2 digit Final Assembly Code (FAC); 

- a 6 digit Serial Number (SNR); and 

- a 2 digit Software Version Number (SVN), 

The IMEISV is formed by concatenating these four elements as illustrated below: 

I TAC I FAC I SNR | SVN | 



Figure A.1: Composition of the IMEISV 



The IMEI is complemented by a check digit as defined in section 3. The modulus 16 Luhn Check Digit (CD) is computed on 
the 14 most significant hexadecimal digits of the IMEISV, that is on the value obtained by ignoring the SVN digits. 
The method for computing the Luhn check, is defined in Annex B of the International Standard "Identification cards - 
Numbering system and registration procedure for issuer identifiers" (ISO/IEC 7812) [31. The modulus 16 Luhn Check Digit is 
identical, but number base has been transformed from 10 to 16. 

In order to specify precisely how the CD is computed for the IMEI, it is necessary to label the individual digits of the IMEISV, 
excluding the SVN. This is done as follows: 

The (14 most significant) digits of the IMEISV are labelled D14 D13 ... Dl, where: 

- TAC = D14 D13 ... D9 (with D9 the least significant digit of TAC); 

- FAC = D8 D7 (with D7 the least significant digit of FAC); and 

- SNR - D6 D5 ... Dl (with Dl the least significant digit of SNR). 

Note: Even though all digits Dl . . . D14 are changed to use hexadecimal coding, this has no effect to the previously assigned 
values of all fields when the fields were using BCD coding. The same code values can still be used for the previously assigned 
codes. The hexadecimal coding allows more codes to be used for all fields. Especially this applies to the SNR field, which has 
number space of 2^24 = 16.777.216 units - with BCD coding the number space is 1.000.000 units. 



A.2 Computation of CD for an IMEI 

Computafion of CD from the IMEI proceeds as follows: 

Step 1: Double the values of the odd labelled digits HDl, HD3, H©5^ ... HD13 of the IMEI using hexadecimal number 
base . 

Step 2: Add together the individual digits of all the seven numbers obtained in Step 1, and then add this sum to the sum 
of all the even labelled digits HD2, HD4, HD6, ... HDI4 of the IMEI using hexadecimal number base . 

Step 3: If the number obtained in Step 2 ends in 0, then set CD to be 0. If the number obtained in Step 2 does not end in 
0, then set CD to be that number subtracted from the next higher hexadecimal number which does end in 0. 
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